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MECHANIZED TAX WORKSHEET 



BACKGROUND 

Field of the Invention 

The present invention is directed to data verification. More particularly, the 
present invention is directed to verifying the accuracy of charges on customer bills 
before the customer bills are sent to the respective customers. 

Background of the Invention 

Large utility companies such a regional telephone companies must generate 
and mail thousands, and typically millions, of customer bills each month. Typically, 
bills are generated in batches on a mainframe computer that stores customer and 
account information. For each batch or billing cycle, the mainframe computer 
collects the relevant charges for each customer, calculates appropriate taxes, tariffs 
and/or other charges, and organizes these several elements into a format that can 
be printed and understood by a customer. 

Telecommunications service billing, and particularly telephone service 
billing, is especially complicated. Using a residential telephone customer as an 
example, one of the only charges on the bill that remains relatively constant from 
month to month, or even from customer to customer, is a monthly service charge 
that all residential customers must pay. However, there are a host of additional 
charges that are included in a typical telephone bill including premium services 
such as call waiting and call forwarding services, emergency 911 charges, late 



payment charges, long distance (toll) charges and bulk item charges such as 
directory assistance. Furthermore, telephone companies typically serve customers 
in several jurisdictions including cities, counties, and states, each having its own 
unique taxing, tariff and/or surcharge paradigm that may be applied in unique 
ways to the several services charged to a customer's account. 

In view of the complexity of the several taxes, tariffs and surcharges that 
may be applicable to a customer's account, it is not uncommon for errors to appear 
on customer bills. Accordingly, large enterprises, such as telephone companies, 

often establish a department that is charged with reviewing the accuracy of 
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ffb customer bills before the bills are sent (ejj., mailed) to customers. This review 

m 

% process amounts to a "sanity check" on the output of the mainframe computer that 

□ is running complex computer algorithms that calculate and, presumably, properly 
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O apply the appropriate taxing and charging schemes to the individual customer 



accounts. Thus, bill verification typically involves obtaining a sample of all or a 
15 batch of bills, and preferably at least a sample from each major jurisdiction, e.g. , a 
state, reviewing those bills, and verifying them for elements such as taxes and 
fractionalization of other charges and credits (OC&Cs). 

The bill verification function is particularly important where the mainframe 
20 computing function is performed by an outside contractor or consultant, Le^, the 

function is outsourced. In such a situation there is significantly less oversight of the 
overall billing process, thereby leading, potentially, to increased billing errors and 
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thus increased customer dissatisfaction and complaints. There may also be legal 
ramifications if customer bills are grossly erroneous. 

The conventional method of conducting bill verification is to manually review 
each sample or "hold" bill, manually identify each of the charges on the bill that is 
subject to taxation, for example, manually calculate the taxes for each charge by 
using tax tables, manually calculate a sum for the charges and compare that sum to 
the data on the "hold" bill. These manual procedures, however, are extremely slow, 
tedious and prone to errors. 

SUMMARY OF THE INVENTION 

To address the urgency of bill verification and to avoid the drawbacks of 
conventional manual bill verification, the present invention provides a mechanized 
tax worksheet that automatically obtains, from mainframe computer data, the data 
that is pertinent to bill verification, e^g., toll charges, bulk charges and other 
charges and credit information, automatically places those elements in a worksheet 
that is displayed on a computer, automatically determines which charges are 
subject to taxing, applies the appropriate tax rate and automatically tabulates total 
taxes and other charges so that error free and efficient bill verification is 
implemented. 



The present invention eliminates, almost entirely, the need for bill verifiers 
to manually identify and manipulate data. Accordingly, the mechanized tax 
worksheet of the present invention also eliminates data entry and calculation errors 
that can occur when bill verification is performed manually. 

In a preferred embodiment of the present invention the mechanized tax 
worksheet operates independently from a mainframe computer that generates 
customer bills. Specifically, the system preferably includes an intermediate server 
for downloading, from the mainframe computer, to a local server billing data 
associated with a customer account. A database is provided and is populated 
directly with a portion of the billing data. Other portions of the billing data undergo 
pre-calculation functions to simplify viewing of the data on a displayed worksheet. 
Taxes applicable to various charges in the billing data are thereafter automatically 
calculated and the results of the tax calculations are saved or stored electronically 
and may be displayed as desired. 

After calculating the taxes independent of the mainframe computer, the 
calculated taxes are compared to the taxes appearing on the corresponding bill 
generated by the mainframe computer. In one embodiment, this comparison step is 
accomplished using a paper copy of a mainframe "hold" bill and comparing the tax 
appearing thereon to the taxes calculated by the present invention. Alternatively, 
the "hold" bill is scanned and its image is made available to the same computer that 
is displaying the independently calculated taxes. In still another preferred 
embodiment of the invention, the scanned image undergoes optical character 



recognition and the data resulting therefrom is then electronically compared to the 
independently calculated taxes. 

It is therefore an object of the present invention to provide an automated or 
mechanized system and method for verifying billing accuracy. 

It is also an object of the present invention to provide a system and method 
for comparing the billing information output from a mainframe computer and 
billing information generated independent of the mainframe computer. 

It is also an object of the present invention to populate a database with data 
pertinent to bill verification and display some or all of the data on a computer. 

It is also an object of the present invention to permit a user to modify data 
pertinent to bill verification. 

It is still further an object of the present invention to electronically compare a 
"hold bill" and an independently calculated bill. 

It is still further an object of the present invention to provide a system and 
method that simultaneously displays "hold bill" data and independently calculated 
bill data. 

It is also an object of the present invention to provide a system and method 
for identifying errors in customer bills by independently calculating bills and 
storing the independently calculated bills for future use. 



These and other objects of the present invention will become apparent upon a 
reading of the detailed description of the invention in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of a preferred embodiment of the present 
invention. 

Figure 2 shows a tax worksheet input screen with exemplary data in 
accordance with a preferred embodiment of the present invention. 

Figure 3 is a services report in accordance with a preferred embodiment of 
the present invention. 

Figure 4 is a tax calculations results screen in accordance with a preferred 
embodiment of the present invention. 

Figures 5A-5B together illustrate a summary report in accordance with a 
preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 illustrates an implementation of a preferred embodiment of the 
present invention wherein a mainframe computer 102 functions as a central billing 
computer for a large enterprise. In the following description, a telephone company 
will be used as the exemplary "large enterprise". However, those skilled in the art 
will appreciate that the present invention is applicable to any enterprise where a 



relatively large number of bills must be periodically generated and a bill verification 
process might be desirable. 

An important aspect of the present invention is the independent verification 
of bills that are generated by mainframe computer 102. To perform useful bill 
verification many of the functions of the present invention are, therefore, 
implemented independently of mainframe computer 102, and most preferably on a 
local server 130 that is in communication with several terminals or personal 
computers (PCs)125 via an electronic data network 120. Data networks, such as 
local area networks, wide area networks and intranets and the like, which are well 

mo known in the art, are suitable for implementing data network 120. Data network 
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=h 120 may also comprise the Internet, especially if bill verifiers (system users) are 
geographically dispersed. 
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In a preferred embodiment of the present invention, mainframe computer 102 
periodically downloads billing information to an intermediate server 105. This 
15 billing information is stored in Mechanized Tax Worksheet (MTW) Database 108, 
which may be separate from local server 130 or, preferably, is coextensive with local 
server 130 as a single data processing machine 135 as shown. In either case, local 
server 130 preferably is capable of reading from, writing to and updating the data 
stored in MTW Database 108. Preferably, intermediate server 105 is periodically 
20 purged of the billing information received from mainframe computer 102 so that 
intermediate server 105 can be utilized for other functions, which may or may not 
be related to billing functions. That is, in the context of the present invention, 



intermediate server 105 may be used only for purposes of facilitating data transfer 
and may even be eliminated altogether if local server 130 can effectively download 
data directly from mainframe computer 102. 

Billing for telephone usage can be divided, generally speaking, into two 
categories: (i) usage or toll type charges and (ii) services and other charges, other 
than toll/usage charges. Usage and toll type charges include, for example, long 
distance charges and directory assistance. On the other hand, services other than 
toll/usage include, for example, standard line charges, local number portability, 
inside wire service and trouble determination plans, call waiting and emergency 
911 charges. Typically, the usage/toll type charges tend to vary during a single 
billing cycle, while the second category of charges tends to be more stable. 

Referring again to Figure 1, the first type of data, toll/usage data, is 
hereinafter referred to as prebill data 140. The second, or relatively more constant 
billing data, is hereinafter referred to as demand print data 145. Prebill data 
preferably is downloaded to local server 130 and stored on MTW Database 108 on, 
e.g ., a daily basis so that this more volatile type of billing information is as up to 
date as possible. More specifically, prebill data is preferably downloaded on the day 
that bill verification takes place. Demand print data may be downloaded less often, 
but preferably at a frequency sufficient to capture changes to the vast majority of 
accounts. Thus, demand print data 145 may be downloaded a few days before bill 
verification with the assumption that this data has remained constant during this 
time. 
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In addition to prebill data 140 and demand print data 145, MTW Database is 
also preferably loaded with tax rate information from Tax TAR (taxing area 
responsibility) database 110. This information preferably includes local tax rates 
and E911 surcharge information by TAR Code. Preferably, but not necessarily, the 
tax rate information that is loaded into MTW Database 108 is the same tax rate 
information that is supplied to and used by mainframe computer 102. This helps 
maintain consistency between the mainframe computer billing calculation and the 
bill verification calculation functions described below. Tax TAR database 110 
and/or a separate revenue directory (not shown) includes information regarding 
which charges among the several charges contained in the prebill and demand print 
data files are taxable as well as the appropriate rate at which the respective charges 
are to be taxed. 

Thus, preferably, two files are created that contain information about 
customer accounts that are to be sampled. A prebill file and a demand print file are 
downloaded to local server 130 (though not necessarily on the same day). At this 
point, many of the data fields in the respective files are loaded directly into MTW 
Database 108. For example, the account telephone number and whether the 
account is a residence or a business are transferred from the appropriate file to a 
record in MTW Database 108 without modification. On the other hand, some of the 
downloaded data is first processed before being stored in the appropriate records in 
MTW Database 108. Specifically, individual late payment charges, emergency 911 
surcharges, directory advertising charges, installment billing charges and toll 
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charges, preferably, are respectively added together so that a single numerical 
value only may represent, on individual lines of the tax worksheet (described 
below), all of these respective charges. Once the pre-calculation is complete, these 
data are also then loaded and stored in the appropriate MTW Database 108 records, 
e.g. , by account number. 

Figure 2 illustrates a tax worksheet input screen in accordance with a 
preferred embodiment of the present invention. The several "cells" in the worksheet 
are preferably automatically filled in once an account number (e.g. , a customer 
telephone number) is entered. The account number then accesses a record of billing 
data that has been stored in MTW Database 108 and "pulls" that data for display on 
the worksheet. Building such "records" in a database is well-known to those skilled 
in the art. The following description of the features of the worksheet of the present 
invention also provides a more detailed description of the data that is downloaded 
from mainframe computer 102. 

In accordance with a preferred embodiment, the present invention is 
implemented in Visual Basic. However, any programming language suitable for 
providing a user interface to a relational database, i.e., MTW Database 108 may 
also be used. 

Referring now to Figure 2, the tax worksheet of the present invention 
includes a menu 210 at the top portion of the worksheet. Menu item "MTW 1 ' has a 
drop down option (not shown) for exiting the worksheet. The next menu item 
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entitled "Operations" includes menu options to "Apply Full Rate" for over-riding a 
discounted rate, "Calculate Taxes" for initiating the application of the taxing rates 
to the various charges and summing the taxes, "Review Tax Results" which changes 
the displayed worksheet to a tax calculations results screen (Figure 4), and "Erase 
All Data" which erases all the data on the input screen and thereby prepares the 
worksheet for a new telephone/account number. 

Under the "Settings" menu, there are options for "Calculate Taxes First," 
which causes the mechanized tax worksheet to jump directly to the tax calculations 
results screen (Figure 4) instead of first showing the data that is displayed in the 
tax worksheet input screen of Figure 2, "Auto-Fill Services," which allow input of 
data with all fields being duplicated except, preferably, for the rate field, and 
"Remarks Preferred," which allows input in the remarks column. Finally, the 
"About" menu item preferably provides details regarding the current version of the 
mechanized tax worksheet of the present invention. 

Area 220 includes a box for the account number which corresponds to the 
account telephone number. There are also boxes for tax exemption indicators (tax 
codes) for the account entered, whether the account is a residence or a business and 
when the next bill period date of the account is. 

Boxes in information area 230 include highlighted symbols that indicate 
whether (i) the screen is permitting remarks to be input, (ii) data is being 
automatically filled (except preferably the rate field), (iii) whether the worksheet is 
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in edit mode (in the edit mode a user can edit or modify the data in any field), and 
(iv) whether to calculate taxes using historical tax rates instead of current tax rates 
(RCATS - refund calculation and tracking system), e.g. , if a refund is due for a 
charge for which the tax rate has now changed. 

Function buttons 240 include a calculate and a review button. If calculate is 
depressed, the summable fields (e.g., rate field) are added together and if the review 
button is depressed, the screen changes to the tax calculations results screen of 
Figure 4. Function box 250 includes an "erase all" button which erases all the 
current data and presents a refreshed mechanized tax worksheet input screen and 
an "exit MTW" button which closes out the program entirely. Preferably, when the 
"exit MTW" button is pressed a dialogue box (not shown) appears which asks the 
user whether he would like to save the worksheet. If yes, the data in the worksheet 
is saved in a conventional manner. 

The main portion of the mechanized tax worksheet input screen (Figure 2) 
includes several columns with headings of "type," "entity," "Tar/Geo," "remarks," 
"from, thru," "A/C" and "rate." The fields in the type column may, for example, be 
one of the following: 



B 



Bill total 



C 



Optional calling services " 



D 



DA charges 



I 



IDB charges - regulated 
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IU 



IDB charges — unregulated 



L 



Local usage 



M RCATS 

N Non-fractional charges & credits 

P Past balance due 

R Recurring charges & credits 

T Tolls 



The entity column represents, in this case, the telephone company that is 
providing service to the customer. Thus, the entity is the billing entity or, in the 
case of telephone companies, the carrier. The Tar/Geo column indicates the Tar 
code or Geographic code that represents the city and county of the account, as is 
well known in the art. The remarks column preferably includes a USOC (universal 
service operations code) or some other brief description of the charge. In Figure 1, 
the following USOCs are used: 



1FRL 



Residential line 



LNPCX 



Local number portability 



BCR 



Secondary CO feature - recurring 



BRD 



Secondary CO feature - recurring 



NXMCR 



Secondary CO feature - recurring 
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AH8KC Kentucky TRS hearing impaired surcharge pass on 

SEQ1X Inside wire service plan 

TDG Trouble determination plan 

8SCRB State universal service fund 

9LM Interstate CALC (end user common line charge) 

VR3CL Residence line 

VSB Secondary CO feature - recurring 



The "from" and "thru" columns are used to bound the dates over which 
certain other charges and credits (OC&Cs) are fractionalized. 

The next column in the mechanized tax worksheet is entitled A/C, or account 
code, for the particular line item. The account code preferably is an internal 
account code used by the billing entity. Finally, the rate column lists the amount of 
charge or credit for the particular line item. 

Figures 3 through 5 illustrate exemplary reports that are output by the 
mechanized tax worksheet of the present invention. Specifically, Figure 3 is a 
services report which provides details of what has been entered into the system for 
a particular account. In this case, Figure 3 has data that corresponds identically to 
Figure 2. 
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Figure 4 illustrates a breakdown of the tax calculations results implemented 
by the mechanized tax worksheet of the present invention. Specifically, as can be 
seen in Figure 4, the tax is broken down by federal, state, county, city and 
franchise. These taxes are calculated using taxing information provided by Tax 
TAR database 110 or tax tables stored within MTW Database 108. Near the bottom 
of the tax results report of Figure 4 are regulated and unregulated totals as well as 
a total billed line. Figures 5 A and 5B show a summary report that is also generated 
by the mechanized tax worksheet of the present invention. This summary report 
preferably is used to compare the several independently calculated charges with the 
charges appearing on the bill calculated by mainframe computer 102, Le., hold bill 
185. 

Specifically, in one preferred implementation, as shown in Figure 1, 
mainframe computer 102 is in communication with printer 180. This printer 
preferably prints several hold bills 185 that correspond to accounts that have been 
downloaded via the prebill and demand print data 140/145. Then, after the 
download process and tax calculation that is completed by the mechanized tax 
worksheet of the present invention, the bill verifier (user) compares the charges on 
the hold bills to the charges that have been independently calculated by the present 
invention. If any inconsistency is apparent, then the bill verifier preferably then 
determines the source of the error, which may be algorithms, etc., run on 
mainframe computer 102 or calculation performed by the mechanized tax worksheet 
of the present invention. Once the bill verifier/user determines that all 
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inconsistencies have been resolved, then the hold bills may be "released" thereby 
permitting release of the complete batch of bills that were held for purposes of 
verification. 

In another preferred embodiment of the present invention, the printed hold 
bills are scanned by scanner 190 and the digital images thereof are made available 
to network 120. Then, these digital images are preferably displayed in split screen 
format on PC 125 along with, for example, the summary report of Figures 5A and 
5B. Thus, in this second preferred embodiment, the bill verifier need not handle 
any papers but instead, can accomplish his function using only a screen of PC 125. 
Of course, two screens may be used, either on the same PC 125, or using two 
separate PCs. 

In still another preferred embodiment of the present invention, optical 
character recognition (OCR) software 195 is provided in connection with the scanner 
whereby the data on the hold bill can be stored electronically. Then, the "compare" 
function that the bill verifier himself performed in the previous embodiment, can, 
instead, be accomplished directly by the present invention by performing electronic 
data comparisons. 

In another embodiment of the present invention, instead of printing hold bills 
185 via printer 180, the data files in mainframe computer 102 that ultimately are 
used to generate the printed hold bills 185 are separately downloaded to local server 
130 and made available to network 120. Then, instead of comparing a printed 
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version of the hold bill to the independently generated verification bill, an electronic 
data comparison can be performed between the two data files, namely, the data files 
from mainframe computer 102 and data files that store the information for, for 
example, summary report of Figures 5A and 5B. In this embodiment, the entire 
process is fully automated whereby a printing step and a manual verification step 
are eliminated. 

A useful by-product of the present invention is that users of the present 
invention can easily be trained to learn the necessary tax information to properly 
work as a bill verifier. Specifically, the present invention, since it is implemented 
on a PC network can easily store individual worksheets that have been calculated. 
Accordingly, if a relatively new user of the present invention has a question 
regarding a possible error generated by the mainframe computer, the user can save 
the worksheet and that worksheet can then be brought up on another computer, 
and even at a later date, for discussion and education purposes. 

Further, the present invention can be used to manually enter data to verify 
taxing or fractionalization outside of the described automated download process. 
This is a very useful tool for quick checking of tax issues. 

The foregoing disclosure of embodiments of the present invention and specific 
examples illustrating the present invention has been presented for purposes of 
illustration and description. It is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. Many variations and modifications of the 
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embodiments described herein will be obvious to one of ordinary skill in the art in 
light of the above disclosure. Thus, the scope of the invention is to be defined only 
by the claims appended hereto, and by their equivalents. 
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